Auch in der Frontend-Entwicklung sind solche Standards entstanden. Allerdings werden sie kaum beachtet. Sie haben leider nie die normative Kraft entfaltet, die ihnen zustehen würde, denn schließlich arbeiten viele unterschiedliche Entwicklertypen mit Frontend-Code. Insbesondere diejenigen, die wenig Kenntnisse und noch weniger Motivation für guten Frontend-Code haben, würden von guten und verständlichen Standards profitieren.

Vor der hilfreichen Benennungsrichtlinie steht aber der richtige Blick auf den Frontend-Code. Dabei müssen wir immer bedenken, dass wir mit HTML und CSS Designs umsetzen, also primär eine Verbindung zur Optik haben, nicht aber zur Programmierung.

Eine Seite besteht aus vielen LEGO-Steinen

Eine Webseite setzt sich aus vielen unterschiedlichen Einzelteilen zusammen: Es gibt einen Header, meist einen Footer und einen mehr oder minder stark unterteilten Inhaltsbereich. Im Inhaltsbereich können sich eine Fotogalerie, Teaser, ein großer Fließtext und vieles andere mehr befinden. Alle diese Bestandteile können und sollten für sich selbst betrachtet werden.

Eine Webseite ist dann eine Zusammenstellung aus vielen Einzelteilen. Meist werden sie aus einem CMS gespeist. Die Analogie zu LEGO liegt auf der Hand. Auch bei LEGO werden Objekte aus unterschiedlich großen Einzelteilen zusammengesetzt.

Im Grunde entwickeln wir keine Seiten, sondern „Systeme“. Die Einzelteile dieser Systeme bezeichne ich als „Module“. Mittlerweile wird auch gerne der Begriff „Patterns“ benutzt. Die Module sind prinzipiell unabhängig voneinander, jedes ist ein eigenes kleines Universum. Gängige Module sind beispielsweise:

• Navigationen
• Linklisten in Seitenleisten oder im Footer
• Teaserboxen – mit oder ohne Bild
• Slider/Karussell
• in einem Akkordeon organisierte Inhalte
• in einem Tabinterface organisierte Inhalte
• eine eingebettete Landkarte

Abb 1: Einzelne Module der Startseite der ZEIT markiert

Abbildung 1 repräsentiert eine nicht mehr aktuelle Version von ZEIT.de. Sie zeigt die modulare Zusammensetzung der Seite. Mitte 2017 sieht die aktuelle Version von ZEIT ONLINE (www.zeit.de) aus wie in Abbildung 2.

Abb. 2: ZEIT ONLINE Mitte 2017 – einzelne Module markiert

Dave Rupert hat in seinem Screenshot des Microsoft-Designs die gleichartigen Module markiert (Abb. 3). Dabei sollte auffallen, dass das Modul „Linkliste“ durchaus unterschiedlich aussieht. Optische Abweichungen sind also kein Grund, ein neues Modul zu erschaffen. Man sorgt stattdessen dafür, dass ein Standard erstellt wird. Und von diesem gibt es mittels zusätzlicher Klassen die notwendigen optischen Abweichungen.

Abb 3: Der Aufbau der 2012 redesignten Seite von Microsoft (Quelle: http://daverupert.com/2013/04/responsive-deliverables)

Erst der Sinn, dann die Optik

Vergessen Sie bitte nie, dass CSS und JavaScript nur die Erweiterungen für die gute Basis, das semantische HTML sind. Bevor Sie also anfangen, die Gestaltung mit CSS umzusetzen, sollten Sie zuerst sinnvolles HTML erzeugen.

Wenn Sie Designentwürfe zur Verfügung haben, drucken Sie sie am Besten aus, schneiden die Module aus und gruppieren diese dann nach Ähnlichkeit. Ähneln sich zwei Module sehr stark – gibt es nur geringe Abweichungen –, so ist die Wahrscheinlichkeit hoch, dass Sie nur ein Modul und eine kleine Modifikation erstellen müssen. Dazu später mehr.

Setzen Sie als Nächstes diese Module in semantischem HTML um. Suchen Sie sich also aus dem größer gewordenen Sprachumfang die passenden Elemente für die jeweiligen Inhalte heraus. Es gibt wesentlich mehr als nur div, p und span. Für die Gestaltung sollten Sie den einzelnen Bestandteilen der Module noch passende Klassennamen geben.

Erst wenn Sie sich Gedanken über das korrekte HTML gemacht haben, sollten Sie sich mit CSS und JavaScript beschäftigen. Und denken Sie immer daran, welches HTML-Element dem Sinn nach genutzt werden sollte, nicht der Optik nach. Schließlich besteht ein Teil der späteren Arbeit darin, die eigentlich gewohnte Optik von Elementen stark zu verändern. Bei Navigationen machen wir dies immer. Niemand sieht ihnen an, dass sie eigentlich Listen sind. Mit ein wenig CSS können auch Absätze ganz schnell wie Listen aussehen (Abb. 4).

Abb. 4: Absätze können wie Listen aussehen (https://goo.gl/tWtyYc)

Layout und Design

Die einzelnen Module sollen später auf der Webseite platziert werden. Diese horizontale und vertikale Verteilung von Inhalten nennen wir „Layout“. Üblicherweise nutzen wir hierfür Grids, meist auf der Basis von Floats. Wenn den einzelnen Modulen dann eine Optik verpasst wird, so sprechen wir von „Design“. Design ist also im Idealfall „schön“.

Das Layout ist unabhängig vom jeweiligen Design, das sich im Wesentlichen mit Farben, Größen und Abständen beschäftigt. Es ist auch unabhängig von den zu verteilenden Inhalten. Deshalb sollten Sie beide Ebenen trennen. Erstellen Sie erst ein Layoutraster, in dessen leere Container Sie dann die Module platzieren. Den Modulen sollte dabei die exakte Platzierung egal sein. Wenn Sie alles richtig gemacht haben, sieht die Navigation immer noch korrekt aus, wenn man sie (auch gerne zusätzlich) in den Seiten-Footer platziert. Ein Beispiel für ein Layoutgerüst (ohne Inhalte) zeigt Listing 1.

Listing 1: Layoutgerüst

<div class="ym-grid">
  <div class="ym-g60 ym-gl">
    <!-- Hier kommt das Inhaltsmodul hin! -->
  </div>
<div class="ym-g40 ym-gr">
    <!-- Hier kommt das Inhaltsmodul hin! -->
  </div>
</div>

Wir diskutieren hierbei nicht über die korrekte Verwendung von Klassen. Mir ist nur wichtig zu zeigen, dass mit dieser einfachen Struktur und diesen wenigen Klassen ein Grid erzeugt wurde. In diesem Fall ist der erste Container 60 % breit und der zweite 40 %. Das Beispiel wurde dem CSS-Framework YAML entlehnt.

In obigem Beispiel sind die Grid-Container ungleich. Nutzen Sie solche Konstrukte, um die Flexibilität Ihrer Module zu testen. Ein Teaser sollte in beiden Containern gut aussehen. Geben Sie den Modulen selber niemals eine Breite und am Besten auch niemals eine Höhe. Angesichts der Vormachtstellung der Smartphones beim globalen Internetzugriff ist Flexibilität eine der Kerneigenschaften für gute Module.

Jedes Modul ist eine eigene Welt

Damit wir im Frontend wirklich modular entwickeln, müssen wir auch die entstehenden Module als eigene Einheiten verstehen. Im CSS beginnen die Selektoren dementsprechend mit dem Modul selber oder einem seiner Bestandteile. Sie sollten immer verhindern, einen Teil des umgebenden DOM mit in die Selektoren zu schreiben (Listing 2).

/* --------- So macht man das! ------------ */
/* Das Modul steht für sich. */
.videowrapper {
  /*  Eigenschaften */
}
.videowrapper iframe {
  /* Eigenschaften */
}

/* ----------- keine gute Idee! ------------ */
/* Was, wenn der Videowrapper demnächst in einem
   anders benannten Container stecken sollte? */

.maincnt .videowrapper {
  /*  Eigenschaften */
}
.maincnt .videowrapper iframe {
  /* Eigenschaften */
}

Die zweite hier vorgestellte Vorgehensweise ist sehr stark verbreitet. Dabei wird der Selektor meist noch viel mehr aufgebläht. Manchmal wird fast das gesamte DOM abgebildet. Das hat zwei Nachteile:

1. Die Spezifität wird (stark) erhöht, sodass es immer schwerer wird, Abweichungen zu definieren. Selbst die Modifikatorklassen würden einen ähnlich komplexen Selektor benötigen. Oder man resigniert und verteilt !important.
2. Die Abbildung von Selektoren vor dem Modul macht das Modul schwer transportabel. Man könnte es in einem anderen Projekt nur dann nutzen, wenn auch dort eine gleich benannte, ähnlich aussehende Struktur existierte. Sollte sich die Struktur der Webseite zwischen Planung und Endversion oder zwischen zwei Projekten grundlegend ändern, ist die Wahrscheinlichkeit hoch, dass solche Selektoren nicht mehr ziehen werden.

Jedes Modul sollte für sich selbst stehen. Erfolgreiche UI-Frameworks wie Bootstrap oder Foundation funktionieren exakt so. Auf den jeweiligen Übersichten stehen beispielsweise mehrere Navigationen untereinander, denen Formulare und Tabellen folgen können. Alle sind aus einem etwaigen Zusammenhang gerissen und sehen trotzdem wie gewünscht aus.

Machen Sie den Test mit Ihrem eigenen Projekt: Erstellen Sie eine Datei ohne den üblichen Rahmen. Nutzen Sie ein vollkommen neues Grid, das Sie in Ihrem Projekt nicht nutzen, und platzieren Sie dann mehr oder minder willkürlich die Module Ihrer Webseite auf dieser Testseite. Sie werden nun auf einen Blick sehen, welche Module eine bestimmte Struktur benötigen, damit sie wie gewünscht aussehen. Mit dem CSS dieser Module beginnen Sie dann die Überarbeitung Ihres Projekts.

Klassen benennen

Es gibt unterschiedliche Methodiken, die sich mit der Benennung von Klassen, dem Aufbau von Selektoren und der Struktur des CSS befassen. Doch bevor Sie sich über die passende Methodik Gedanken machen, sollten Sie für sich (und Ihr Team) ein paar Grundregeln abstimmen:

1. Nutzen Sie englisch- oder deutschsprachige Klassennamen? Englischsprachige haben den Vorteil, dass sie keine Hürde darstellen, wenn Sie einmal bei Stackoverflow eine Frage mit Codebeispielen haben. Entscheiden Sie sich für eine Sprache und bleiben Sie dabei konsistent.
2. Die Klassennamen sollten nicht eng an die Optik gekoppelt sein. Eine Klasse .blue ist nur so lange praktisch, bis man die damit verbundene Gestaltung auf Kunden- oder Designerwunsch in rot ändern muss.
3. Zu enge inhaltliche Verknüpfungen sind aber auch nicht praktisch, denn eine .sponsortable kann prima auch für eine Tabelle genutzt werden, in der Kundenlogos stehen. .imagetable wäre evtl. eine bessere Wahl. Der Name sollte also eine gesunde Balance zwischen Abstraktion und inhaltlicher Beschreibung wahren. Das ist nicht einfach, aber ein erreichbares Ziel.

Klassennamen nach BEM

Die Systematik BEM (Block Element Modifier) hat sich in den letzten Jahren als Quasistandard im Frontend durchgesetzt. Ersonnen wurde BEM von Entwicklern der russischen Suchmaschine Yandex. Das System ist in Wahrheit sehr viel größer und umfassender, uns interessiert nur der CSS-Teil. Der Charme von BEM sind sicherlich seine rigiden Benennungsregeln. Sie sind Vor- und Nachteil zugleich.

Ein Modul einer Webseite wird als „Block“ bezeichnet. Ein Block besteht wiederum aus mehreren Elementen. Die Darstellung dieser Elemente kann durch Modifier verändert werden. In der Dokumentation fungiert eine Navigation als Beispiel. Die Navigation ist hierbei der Block. Die einzelnen Links – egal wie sie gestaltet sind – sind die Elemente. Die Formatierung als vertikale oder horizontale Navigation, als Reiter oder Buttons, geschieht dann über die Zuweisung der passenden Modifier.

Wir haben also eine Trennung zwischen Grundstyles und Modifikationen. Auch der BEM-Ansatz geht davon aus, dass wir kein komplett neues Modul benötigen, nur weil es ein wenig anders aussieht als ein in der Struktur ähnliches oder gleiches.

Die Namensgebung erfolgt bei BEM durch schlichte und strikte Regeln. Die drei Bestandteile des BEM-Ansatzes sind sauber durch die Benennungsregeln identifizierbar. Dabei werden doppelte Binde- und Unterstriche genutzt. Die Grundidee ist Folgende:

.block {}
.block__element  {}
.block--modifier {}
.block__element--modifier {}

In einem praktischen Beispiel kann das dann so aussehen:

.speech-bubble{}
.speech-bubble__header{}
.speech-bubble__text{}
.speech-bubble__text--link{}

Die einzelnen Elemente und Modifier werden im Grunde genommen mit dem Namen des Moduls als Namespace versehen. Das passiert, um eine niedrige Spezifität zu bewahren. Denn je mehr Bestandteile ein Selektor hat, desto spezifischer ist eine Regel. Auch eine ID kann eine sehr hohe, fast nicht zu schlagende Spezifität darstellen.

Die Idee hinter allen bekannten Benennungsrichtlinien ist, die Spezifität der Selektoren so klein wie möglich zu halten. Bei BEM wird eine Klasse nur innerhalb eines Moduls genutzt. Die mehrfache Verwendung einer Klasse innerhalb verschiedener Module ist nicht vorgesehen, schließlich arbeiten alle Klassen mit einem Modulpräfix.

Keine starren Regeln

Die rigiden Regeln von BEM funktionieren dann besonders gut, wenn Sie ein großes Team haben, in dem die CSS-Kenntnisse sehr unterschiedlich verteilt sind. Wenn Sie hingegen Entwickler mit sehr guten CSS-Kenntnissen haben, können diese rigiden Regeln auch störend wirken. Denn sehr geübte Frontend-Entwickler möchten auch gerne schlanken Code schreiben. Bei einer einfachen Navigation ohne Unternavigation wäre es unnötig, den Listenelementen und Links eigene Klassen zu geben. HTML würde unnötig vollgemüllt werden. Über einfache Kontextselektoren und eine Klasse auf der Navigationsliste könnte man jedes Element der Navigation erreichen und gestalten. Nach BEM sähe die Navigation folgendermaßen aus:

<ul class="navigation">
  <li class="navigation__item">
    <a href="#" class="navigation__link">Link</a>
  </li>
  <li class="navigation__item">
    <a href="#" class="navigation__link">Noch ein toller Link</a>
  </li>
  <li class="navigation__item">
    <a href="#" class="navigation__link">Der ist noch besser!</a>
  </li>
</ul>

Das dazugehörige CSS sähe dann so aus:

.navigation {/* Eigenschaften */}
.navigation__item {/* Eigenschaften */}
.navigation__link {/* Eigenschaften */}

Die meisten Klassen sind allerdings unwichtig, deshalb könnten Sie das HTML auch folgendermaßen auszeichnen:

<ul class="navigation">
  <li>
    <a href="#">Link</a>
  </li>
  <li>
    <a href="#">Noch ein toller Link</a>
  </li>
  <li>
    <a href="#">Der ist noch besser!</a>
  </li>
</ul>

Das dazugehörige CSS:

.navigation {/* Eigenschaften */}
.navigation li {/* Eigenschaften */}
.navigation a {/* Eigenschaften */}

In solch eng abgrenzbaren Fällen, in denen wir eine klare, nicht zu verändernde Struktur erwarten können, empfinde ich es als wohltuend, Klassen in HTML einzusparen und die in CSS aus guten Gründen vorgesehenen Elementselektoren zu nutzen. Aber schon bei einer Navigation mit Subnavigation(en) nehme ich wieder Abstand von der oben beschriebenen Ausnahme. Der Nutzen von Klassen ist in solchen Momenten einfach zu hoch, wie Listing 3 illustriert.

<ul class="navigation">
  <li class="navigation__first-level-item">
    <a href="#" class="navigation__first-level-link">Link</a>
  </li>
  <li class="navigation__first-level-item">
    <a href="#" class="navigation__first-level-link">Noch ein toller Link</a>
    <ul class="navigation__second-level">
      <li class="navigation__second-level-item">
        <a href="#" class="navigation__second-level-link">Link im Submenü</a>
      </li>
      <li class="navigation__second-level-item">
        <a href="#" class="navigation__second-level-link">Noch ein Link im Submenü</a>
      </li>
      <li class="navigation__second-level-item">
        <a href="#" class="navigation__second-level-link">Link im Submenü</a>
      </li>
    </ul>
  </li>
  <li class="navigation__first-level-item">
    <a href="#" class="navigation__first-level-link">Der ist noch besser!</a>
  </li>
</ul>

Ich sehe durchaus den Nutzen strikter Regeln. Sollten aber die Projektbeteiligten genügend CSS-Wissen besitzen, empfinde ich begründete Ausnahmen von der Regel als einen Segen. Sie vermeiden unnötig aufgeblähtes HTML.

Achten Sie darauf, bei BEM nicht mit den Klassennamen das DOM abzubilden. Vergeben Sie also niemals Enkelelemente. Schauen wir uns etwa das Beispiel aus Listing 4 an.

<div class="teaser">
  <header class="teaser__headercontainer">
    <h3 class="teaser__headercontainer__header">Überschrift</h3>
  </header>
  <div class="teaser__content">
    <p class="teaser__content__paragraph">Lorem Dingenskirchen und so weiter, ihr wisst schon ....</p>
  </div>
  <footer class="teaser__footer">
    <a href="linkziel.html" class="teaser__footerlink">weiterlesen ...</a>
  </footer>
</div>

Alle Klassennamen beziehen sich in diesem Beispiel auf das jeweilige Elternelement. Dadurch wird eine konkrete Struktur festgelegt. Sollte das header-Element nicht mehr benötigt werden, würde sich eine einsame h3 auf ein nicht existentes Element beziehen. Das Gleiche gilt für den Absatz. Alle Klassennamen sollten sich ausschließlich auf den Namen des Moduls beziehen. Aus .teaser__headercontainer__header würde dann .teaser__header. Der bessere Code sähe also wie in Listing 5 aus.

<div class="teaser">
  <header class="teaser__headercontainer">
    <h3 class="teaser__header">Überschrift</h3>
  </header>
  <div class="teaser__content">
    <p class="teaser__paragraph">Lorem Dingenskirchen und so weiter, ihr wisst schon ....</p>
  </div>
  <footer class="teaser__footer">
    <a href="linkziel.html" class="teaser__footerlink">weiterlesen ...</a>
  </footer>
</div>

Eine weitere Einschränkung der Klassennamen ergibt sich aus der Natur der Texterstellung. Wird der Absatz im obigen Beispiel direkt vom Redakteur erstellt, und könnte es sich dabei auch um mehrere Absätze oder eine Liste handeln? Wenn ja, dann können Sie nur noch sinnvoll mit Kontextselektoren arbeiten. Schließlich müssen Sie verhindern, dass Redakteure Klassen in ihren WYSIWYG-Editoren vergeben oder gar HTML schreiben/überprüfen müssen. Nur wenn Sie die komplette Kontrolle über den Quellcode haben, können Sie jedem Element eine Klasse geben. Für alle anderen Fälle gibt es Kontextselektoren. Diese gehören zum CSS-Sprachumfang und sind nicht giftig.

Unterschiedliche Arten zu stylen

Grundsätzlich stehen uns viele unterschiedliche Arten zur Verfügung, um mittels CSS Gestaltung in die HTML-Elemente und ihre Inhalte zu bringen. Alle haben ihre Berechtigung, keine ist wirklich falsch. Wir können beispielsweise mit Klassen gestalten, mit Kontextselektoren oder mit Pseudoselektoren. Egal, wie wir vorgehen, diese beiden Aspekte sind zu beachten:

1. Wiederverwendbarkeit innerhalb des Projektes und zwischen Projekten
2. Module im Sinne abgekapselter Inhalte

Da mir diese beiden Aspekte sehr wichtig sind, fällt für mich die Möglichkeit aus, nur mit Element- und Pseudoselektoren unter Ausnutzung unterschiedlicher Kombinatoren zu gestalten. Wir haben in meinen Augen zwei grundsätzlich unterschiedliche Ansätze zur Verfügung, wie wir Module unseres Designs gestalten und modifizieren können:

1. Wir vergeben eine Basisklasse und ergänzen sie optional durch einen oder mehrere Modifikatoren. Damit gestalten wir also durch eine Klasse oder eine Kombination mehrerer.
2. Wir regeln alle Abweichungen und Standards im CSS und vergeben nur jeweils eine einzelne Klasse.
3. Ein gern zitiertes Beispiel sind hier Buttons. Im Modifikatoransatz würden wir eine Basisklasse vergeben, die schon eine Designvariante darstellt. Der Modifikator ändert dann Details wie Größe, Farben oder Icons (Listing 6).

<!-- Standardbutton -->
<button class="btn">Klick mich!</button>

<!-- Button mit warnender Farbe -->
<button class="btn btn-warning">Warnung</button>

<!-- Link als Button formatiert, mit Icon -->
<a href="#" class="btn btn-ico-print">drucken</a>

Der auf CSS fokussierte Ansatz ist dann besonders praktisch, wenn man einen Präprozessor wie Sass nutzt. Mit Sass könnten Sie ein Mixin oder einen Platzhalter schreiben, in dem Sie die allgemeinen Regeln für Buttons definieren. Diese werden dann allen Buttonvarianten zur Verfügung gestellt, ohne selbst als Klasse ausgegeben zu werden. Dadurch können Sie einem Element immer exakt eine Klasse geben (Listing 7).

@mixin btn { 
/* Platzhalter mit allgemeiner Buttondefinition */
}

/* Standardbutton */
/* Mit @include werden die Eigenschaften des Mixins btn übernommen.
   Am Ende werden mehreren kommaseparierten Selektoren
   die Eigenschaften zugewiesen, die identisch sind. */
.btn {
  @include btn;
}

/* Button mit warnender Farbe */
.btn-warning {
  @include btn;
  color: $btn-warning-col;
  background-color: $btn-warning-bgcol;
}

/* Link als Button formatiert, mit Icon */
.btn-ico-print {
  @include btn;
  color: $btn-ico-print-col;
  padding-left: 10px;
  background: $btn-ico-print-bgcol image-url($btn-ico-print-icon) no-repeat left center;
}

Dieses Beispiel verzichtet auf Platzhalter zugunsten von Mixins. Platzhalter haben den Nachteil, dass sie nicht am Ort des Aufrufs in das CSS geschrieben werden sondern dort, wo der Platzhalter generell importiert wird. So werden die Regeln für ein Modul zwangsweise auseinandergerissen.

Der erste Ansatz, bei dem durch Klassen in HTML gestaltet wird, ist sehr gut für Rapid Prototyping geeignet, da man sich auf Inhalt und Struktur konzentrieren kann. Zur Gestaltung muss CSS weder geschrieben noch modifiziert werden. Einfache Regeln ermöglichen ein grundsätzliches Design, an dem dann später eventuell weitergearbeitet wird. Allerdings werden viele Klassen in HTML geschrieben. Und eine Designänderung erfordert eine Änderung an HTML (Austausch einer Klasse), anstatt sie in CSS vorzunehmen.

Beim zweiten, auf CSS konzentrierten Ansatz werden wenige Regeln dupliziert. CSS wächst unweigerlich an, dafür bleibt HTML ein wenig kompakter. Es ist unnötig, sich theoretisch für eine der beiden Varianten zu entscheiden. Aus der konkreten Projektsituation heraus sollte einer der beiden Wege eingeschlagen, dann aber auch konsequent zu Ende gegangen werden.

Jedes Modul eine Datei

Präpozessoren haben einen weiteren immensen Vorteil für die Entwicklung modularer Systeme: Als Entwickler können Sie jedem Modul eine eigene Datei geben und in eine zentrale Datei importieren lassen. Am Ende wird eine einzige CSS-Datei erzeugt, die dann mit dem Webprojekt verknüpft wird. Sie selber arbeiten aber in vielleicht hundert oder zweihundert Einzeldateien. Das macht die Organisation des eigenen Codes einfacher und fördert die Arbeit im Team. Es erleichtert auch den Transport von Code zwischen Projekten, denn Sie sollten niemals aus den Augen verlieren, dass Sie einmal geschriebenen Code mehrfach verwenden können und auch sollten.

Fazit

Mit der richtigen gedanklichen Herangehensweise schaffen Sie es, Ihren Frontend-Code wartbar zu machen und zu halten. Dafür benötigen Sie Wissen über die Grundlagen von CSS und Willen zu semantisch genutztem HTML. All dies muss stringent durchgehalten werden. Wenn Sie Frontend-Code genauso ernst nehmen wie Backend-Code, sollte dies kein Problem sein. Je weniger Detailwissen zu CSS vorliegt, umso wichtiger ist es, dass ein System wie BEM strikt gehandhabt wird. Einigen Sie sich im Team auf Coding-Richtlinien und kontrollieren Sie sie. Diese Kontrolle können Sie teilweise auf Linter (mit Grunt oder gulp gesteuert) auslagern, eine persönliche Kontrolle ist hingegen besser.